There are a variety of techniques for determining whether a manufactured part or design has faults or defects. In order to determine the effectiveness of such tests, it is necessary to have a measure of the test's efficacy in locating faults or defects. Such test evaluation techniques, called test or fault grading, give a coverage measure which indicates how good the tests are in locating defects or faults.
Faults model fabrication defects. A designer can then determine if a set or program of test patterns, called test vectors, can detect an acceptable percentage of faults.
Most fault coverage systems rely on the stuck at fault model which assumes that each tested node is stuck at zero or stuck at one. With this assumption, a test is run to see if a given task or test vector can detect a particular stuck at fault. Common stuck at faults could include tying nodes high or low for the entire test, a metallization that is stuck open or shorted, faults that occur between adjacent runs, shorted pins, or shorts to ground or power supply.
Fault coverage is the extent to which a given set of test vectors can detect faults. If a given set of test vectors can detect 50% of all simulated stuck at one or zero faults in a given system, it has a coverage of 50%. Generally, the fault coverage depends on the testability of the logic design to some degree and also the comprehensiveness of the test vectors.
Commercial testers may use machine language test programs. In testing microprocessors, these tests might be run for a matter of seconds because the testers are expensive. As a result, a relatively short program of test vectors is necessary and it may then be unclear whether good coverage was always achieved. Such a methodology puts a high premium on locating the best set of test vectors to give the best coverage. One attempts to improve the coverage by making intelligent assumptions about the defect behavior for a given product.
Thus, in one conventional methodology used in microprocessors and other complex systems, a test is run on a commercial tester to determine the presence of defects over a few seconds of code in order to make the test economical. The effectiveness of these short duration tests can be evaluated using the stuck at fault model. As systems become more complex, the efficacy of these short tests, using the structural tester, has come to be questioned.
As a result, system tests have been used in place of expensive structural testers. In the system test, commercial operating system or application machine language software may be run for a more extended period of time on the order of a minute or more. In effect then, a rather large system test vector set is utilized.
Because of the complexity of this test it is not possible to use the traditional stuck at fault model to determine the test quality. This is because the stuck at fault model is basically a gate level model. It would be difficult to determine over an extended period of time with a program running at relatively high speed (such as 200 megahertz or greater) whether or not the coverage was acceptable.
For example, to simulate one second of program, it would take approximately 20,000 days of CPU time (on a leading edge server) to fault simulate 2,000 fault samples for a 6 million transistor CPU design.
The basic methodology of using the system level test is to start with a relatively large program of extended time and to trim out the parts of the program that do not detect defects in a given system. After these parts are trimmed away, the remaining time is then assumed to be effectively used in locating defects. Of course, one problem is that if the underlying model changes (which may occur when there is an essential process change or perhaps even a change in fabrication facility), it is no longer clear whether the system test can be relied upon.
Thus, there is a continuing need for simulation-efficient coverage measures useful for testing complex systems such as microprocessors.